Skip to main content
Quang Liem
💬
0 discussions

Database Design

I. Applied Technologies​

1. Multi Tenancy​

Multi-Tenant - Multi-tenancy có nghĩa là một phiên bản duy nhất của phần mềm và cơ sở hạ tầng hỗ trợ của nó phục vụ nhiều khách hàng. Mỗi khách hàng chia sẻ ứng dụng phần mềm và cũng chia sẻ một cơ sở dữ liệu. Dữ liệu của mỗi người khách hàng bị cô lập và vẫn vô hình đối với những khách hàng khác.

Có 3 phương án multi tenant

  • Separate DB: Ở phương án này hệ thống sẽ gồm 1 database chung (chuyên để quản lý các phần như danh sách tenant, user, role ...), 1 database tenant chuẩn (chứa dữ liệu chuẩn), và các tenant khác. Mỗi tenant sẽ là 1 database, người dùng sẽ có quyền truy cập vào database chung và database tenant của user đó.

  • Shared DB - Shared Table: Ở phương án này thông tin các tenant sẽ được lưu trữ cùng database cùng table, dữ liệu của các tenant được phân biệt vơí nhau bằng 1 khóa ngoại.

  • Shared DB - Shared Schema: Ở phương án này mỗi tenant tương ứng 1 schema. Có một schema chung để quản lý những các dữ liệu chung, quản lý thông tin về tenants. Cấu trúc các bảng ở tất cả các tenant đều giống nhau. Cần 1 schema chuẩn để dựa vào đó tạo ra tenant mới trong quá trình thêm mới tenant.

2. Database Versioning​

Trong quá trình vận hành database có thể được thay đổi, nâng cấp theo thời gian. Thông thường vấn đề này gặp nhiều khó khăn thay đổi cấu trúc dữ liệu, để giải quyết vấn đề này chúng ta áp dụng schema versioning. Trong schema versioning các document được đánh dấu bằng một biến schema_version và khi có thay đổi chúng ta có thể tăng giá trị của schema_version này.

Tương tự như schema versioning cho document, chúng ta có thể áp dụng api versioning để giải quyết vấn đề thay đổi, nâng cấp cho các api. Api versioning chia api thành các phiên bản khác nhau như v1, v2,.. các phiên bản thường được cấu trúc ở các thư mục riêng biệt.

II. Critical Practices in Gcalls​

1. Những đặc điểm Multi Tenancy ở Gcalls​

Kiến trúc Gcalls áp dụng giải pháp multi tenancy (shared database - shared schema) để xây dựng và thiết kế cơ sở dữ liệu. Ở giải pháp này, khi một tenant mới được khởi tạo, ngoài lưu các thông tin cơ bản của tenant ở database access service. Mỗi tenant sẽ tương ứng 1 schema. Sử dụng 1 schema chung để quản lý những thông tin chi tiết, danh sách của các tenants. Các tenants sẽ có cấu trúc table giống như nhau.

1 schema với cấu trúc table chuẩn để  từ đó tạo ra tenant mới trong quá trình hoạt động hệ thống.

Ở mô hình này mỗi tenant schema sẽ gồm các cấu trúc collections ở user service và customer service. Mỗi collection sẽ có idCallcenter của tenant đó ở tên.

2. Những đặc điểm Database Versioning ở Gcalls​

2.1. Document Versioning​

Gcalls áp dụng Model Data for Schema Versioning ở mongodb. Trường _v được thêm vào schema document để đánh dâu version hiện tại của document, các document được thêm, sửa phải được cập nhật _v.

Tương tự thêm, sửa các hoạt động get document cũng được filter với trường schema version. Hiện tại version schema của document là 1.0.

2.2. API Versioning​

Các api của Gcalls hiện được chia thành 2 phiên bản với v1 là phiên bản đang được sử dụng và được cấu trúc trong thư mục riêng biệt route/v1 ở các service backend.

Cấu trúc hiện tại của api

{host}/api/{version}/{path}

2.3. Lưu ý​

Khi schema là v1 thì đi với bộ api v1, hiện tại hệ thống đang sử dụng v1

Schema versioning được config ở ENV của middle service sau đó update vào database, tham khảo đoạn code sau :

III. Các loại Database đang được sử dụng​

1. Mongo​

  • Bao gồm các database chính của các service, để lưu trữ các thông tin để hệ thống hoạt động. Chi tiết từng bảng bao gồm sẽ được mô tả ở các service liên quan .

  • Được kết nối trực tiếp với các backend service

  • Data ở Mongo được backup hàng đêm thông qua cronjob

    Khi nào cần sử dụng :​

  • Dùng khi cần truy xuất, kiểm tra thông tin trong database ( dành cho các kỹ sư đã nắm chắc DB, không được tự ý chỉnh sửa thông tin khi chưa thông báo và được team review ), và khi cần xử lý logic ở tầng backend, và thay đổi cấu trúc dữ liệu ở database

  • Mongo : Tổng cộng 5 Node Các Node được phân tán ra 2 physical zone trong 1 data center

  • Auth :
    • Private Network
    • Firewall ( Bizfly)
    • IP Table ( Linux )
    • Login : Connection String
  • Bao gồm 1 Primary Node, 1 Hidden Node (Dùng để backup - data ở node này chậm hơn 1 tiếng), 3 Secondary Node

2. Redis​

Redis : Có 2 Redis

Redis 1- Server Redis:​

  • Được kết nối với webphone-service, mobile-service
  • Được sử dụng khi : dùng để cache thông tin user, quản lý session sau khi User đăng nhập
  • Cấu trúc :
  • Auth :
    • Private Network
    • Firewall ( Bizfly)
    • IP Table ( Linux )
    • Login : Connection String

Redis 2 - Server ContactHub​

  • Kết nối với command service

  • Được sử dụng khi : cần cache các thông tin ở command service

  • Auth :

    • Private Network
    • Firewall ( Bizfly)
    • IP Table ( Linux )
    • Login : Connection String

Cài đặt​

3. PSQL​

  • PSQL : Dùng để quản lý thông của Keycloak ( Cloud DB - Bizfly)
  • Được sử dụng khi : Cài đặt Keycloak, migrate data của Keycloak
  • Auth :
    • Private Network
    • Firewall ( Bizfly)
    • IP Table ( Linux )
    • Login : Connection String

4. CouchDB​

  • Có 2 bảng chính : calllog-system, calllog-gcalls

  • Auth :

    • Public Network
    • IP Table ( Linux )
    • Login : Connection String

Dùng để lưu raw data ( calllog ) từ bản tin SIP được nhận từ pbx (filelua), callbox. Sau khi data được làm sạch ở RawService thì sẽ được lưu vào Mongo, Salesforce (incoming, missed call)

  • Được sử dụng khi : Config rawservice, config calllbox, các luồng logic liên quan đến rawService

  • calllog-system : chứa Raw calllog từ file LUA

  • calllog-gcalls : chứa Raw calllog từ calllbox

IV. Kết Luận​

  • Tài liệu này nhằm mục đích giúp người đọc hiểu về cách thiết kế dữ liệu trong hệ thống bằng các kỹ thuật như : Separate DB, Shared Table, Shared Schema, Document Versioning, API Versioning

Trên đây là tổng quan về database design được áp dụng trong hệ thống Gcalls. Nếu có câu hỏi nào vui lòng điền vào form bên dưới.